LLM Wiki：用 LLM 构建个人知识库的一种模式
2026 年 4 月，前 Tesla AI 总监、OpenAI 研究员 Andrej Karpathy 发了一条推文，讲自己如何用 LLM 做个人知识库，阅读量超千万。随后他写了一份完整的设计文档，引发了社区的大量实现和讨论。本文基于 Karpathy 的原始文档和社区实践，对 LLM Wiki 的理念、架构和实现做系统性说明。
一、LLM Wiki 是什么
先说问题
大多数人用大模型处理文档的方式叫 RAG（检索增强生成）：你扔一堆文件进去，每次提问时模型临时翻找、临时拼凑答案。能用，但知识没有积累。问一个需要综合五份文档才能回答的问题，模型每次都得从零开始找、从零开始拼。什么都没沉淀下来。NotebookLM、ChatGPT 的文件上传、大多数 RAG 系统都是这样工作的。
LLM Wiki 的思路
Karpathy 的思路反过来：别让模型每次临时翻书了，让它替你维护一套持续更新的笔记。
具体说，就是让 LLM 把你喂给它的资料逐步编译成一组互相链接的 Markdown 文件（也就是一个 wiki），像程序员维护代码库一样。每加一份新资料，模型不会只是存起来，它会读懂、提取要点、更新已有页面、标注矛盾、补充交叉引用。知识被「编译」一次就沉淀下来，越积越厚。
关键区别：RAG 的知识停留在原始文档里，每次查询重新发现；LLM Wiki 的知识被编译成结构化的 wiki 页面，交叉引用已经建好了，矛盾已经被标记了，综合判断已经反映了你读过的所有内容。
用 Karpathy 的话说：
Wiki 是一个持久的、不断复利增长的产物。每添加一个新资料源、每提出一个新问题，wiki 都在变得更丰富。
分工
| 角色 | 职责 |
|---|---|
| 人类 | 选资料、问问题、做判断、决定研究方向 |
| LLM | 总结、归档、交叉引用、保持一致性、维护索引和日志 |
人类之所以会放弃维护 wiki，是因为维护负担的增速超过了价值增速。LLM 消除了这个瓶颈——它不会烦、不会忘、一次操作能同时更新十几个页面。
操作方式
Karpathy 描述的实际工作流：
一边开着 LLM Agent（能执行操作的 AI 助手，不只是聊天，还能读写文件、运行命令），一边开着 Obsidian（一款流行的本地 Markdown 笔记软件，支持双向链接和图谱视图）。LLM 根据对话进行编辑，用户实时浏览结果——跟踪链接、查看图谱视图、阅读更新后的页面。
Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。
适用场景
- 个人领域：追踪目标、健康、心理——归档日记、文章、播客笔记，构建关于自己的结构化全景
- 研究领域：数周或数月深入一个课题——阅读论文、文章、报告，逐步构建带有演进论点的综合性 wiki
- 阅读一本书：逐章归档，为人物、主题、情节线索建立页面，标注关联。读完后拥有一部丰富的伴读 wiki（想想 Tolkien Gateway——数千个互相链接的页面）
- 商业/团队：由 LLM 维护的内部 wiki，输入来源是 Slack 讨论、会议记录、项目文档、客户通话
- 其他：竞争分析、尽职调查、旅行规划、课程笔记、爱好深挖
二、三层架构
LLM Wiki 分为三层，各层职责清晰：
1. 原始资料源（Raw Sources）
你精心筛选的源文档集合。文章、论文、图片、数据文件。
只读——LLM 从中读取但绝不修改，原始资料永远保持原样。这是你的权威来源（source of truth），当信息冲突时以此为准。
2. Wiki
一个由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、对比分析、概览、综合判断。
完全由 LLM 拥有——它创建页面、在新资料到达时更新页面、维护交叉引用、保持一切一致。你负责阅读，LLM 负责写。
3. Schema（模式定义）
一份配置文档（比如 Claude Code 的 CLAUDE.md 或 OpenAI Codex 的 AGENTS.md），定义 wiki 的结构是怎样的、约定是什么、在摄入资料、回答问题或维护 wiki 时应遵循什么工作流。
这是关键配置文件——它让 LLM 成为一个有纪律的 wiki 维护者，而非一个通用聊天机器人。随着你对自己领域的理解加深，你和 LLM 会一起迭代这份文档。
my-wiki/
├── raw/
│ ├── sources/ # 原始资料（只读）
│ └── assets/ # 本地图片
├── wiki/
│ ├── index.md # 内容目录
│ ├── log.md # 操作日志
│ ├── overview.md # 全局概要
│ ├── entities/ # 实体页面（人物、组织、产品）
│ ├── concepts/ # 概念页面（理论、方法、技术）
│ ├── sources/ # 资料摘要
│ ├── synthesis/ # 跨资料综合分析
│ └── comparisons/ # 并列对比
├── schema.md # 结构规则
└── purpose.md # 目标和方向（可选）
三、三个核心操作
1. 摄入（Ingest）
你把新资料放进原始资料集，然后让 LLM 处理它。一个典型流程：
- LLM 阅读资料
- 与你讨论关键要点
- 在 wiki 中写一个摘要页面
- 更新索引（index.md）
- 更新 wiki 中相关的实体和概念页面
- 在日志（log.md）中追加一条记录
一个资料源可能触及 10-15 个 wiki 页面。 比如你摄入一篇关于某公司收购案的新闻，LLM 可能需要更新：收购方公司页面、被收购方公司页面、CEO 页面、行业概览页面、相关概念页面（如「并购整合」）、以及新闻本身的摘要页面。
Karpathy 的个人偏好是逐条摄入并全程参与——读摘要、检查更新、引导 LLM 强调什么。但也可以批量摄入大量资料，减少监督。怎么做取决于你自己，找到适合你的工作流后，记在 Schema 里。
2. 查询（Query）
你针对 wiki 提问。LLM 搜索相关页面、阅读它们、综合出带引用的答案。
答案可以根据问题采取不同形式——一个 Markdown 页面、一个对比表格、一套幻灯片（Marp）、一张图表（matplotlib）、一个画布。
重要洞察：好的答案可以作为新页面归档回 wiki。 你请求的一次对比分析、一个分析结论、你发现的一个关联，这些都值得留下来，不应该消失在聊天历史中。这样，你的探索就像摄入的资料源一样，在知识库中实现复利增长。
3. 检查（Lint）
定期让 LLM 对 wiki 做健康检查，寻找：
- 页面之间的矛盾
- 已被更新资料取代的过时论断
- 没有任何入站链接的孤儿页面（orphan pages）
- 被提及但缺少独立页面的重要概念
- 缺失的交叉引用
- 可以通过网络搜索填补的数据缺口
LLM 擅长建议新的调查问题和新的资料来源。这让 wiki 在增长过程中保持健康。
四、索引与日志
两个特殊文件帮助 LLM（和你）在 wiki 增长时进行导航。
index.md —— 内容目录
wiki 中所有内容的目录——每个页面列出链接、一行摘要、以及可选的元数据（如日期或资料源计数）。按类别组织（实体、概念、资料源等）。LLM 在每次摄入时更新它。
回答查询时，LLM 先读索引找到相关页面，再深入查看。这在中等规模（约 100 个资料源、数百个页面）下效果出奇地好，避免了基于 embedding 的 RAG 基础设施的需求。
# Wiki Index
## 实体
- [[张三]] — 某公司 CTO，主导了 X 项目
- [[某公司]] — 成立于 2020 年，专注 AI 领域
## 概念
- [[Transformer]] — 注意力机制架构，BERT 和 GPT 的基础
- [[RAG]] — 检索增强生成，结合外部知识的 LLM 应用模式
## 资料源
- [[2024-01-15 某公司融资新闻]] — B 轮融资 5000 万美元
- [[Attention Is All You Need]] — Transformer 原始论文
log.md —— 操作日志
一个只追加的记录（append-only），记录发生了什么以及何时发生——摄入、查询、检查。
实用技巧：如果每条记录以统一前缀开头（如 ## [2026-04-02] ingest | Article Title），日志就可以用简单的 Unix 命令行工具解析：
grep "^## \[" log.md | tail -5 # 最后 5 条记录
grep "ingest" log.md # 所有摄入记录
# Log
## [2026-04-02] ingest | Attention Is All You Need
- 创建页面：[[Transformer]], [[Self-Attention]]
- 更新页面：[[深度学习]], [[NLP]]
- 新增交叉引用 4 条
## [2026-04-02] query | Transformer 和 RNN 的区别
- 检索页面：[[Transformer]], [[RNN]], [[序列模型]]
- 生成对比页面已归档至 wiki/comparisons/
## [2026-04-03] lint
- 发现 2 个孤儿页面
- 发现 1 处矛盾：[[某公司]] 成立时间在两个页面中不一致
五、可选工具链
Obsidian
一款本地 Markdown 笔记软件，支持双向链接和图谱视图。LLM Wiki 的 wiki 目录可以直接作为 Obsidian 仓库使用——LLM 在后台编辑文件，你在 Obsidian 中实时浏览结果。
关键功能：
- 图谱视图（Graph View）：以节点和连线可视化所有笔记之间的链接关系，是查看 wiki 全貌的最佳方式——什么和什么连接在一起，哪些页面是枢纽，哪些是孤儿
- 双向链接：
[[页面名]]语法，自动建立反向链接 - Web Clipper：浏览器扩展，把网页文章转换为 Markdown，快速收入原始资料集
图片下载技巧：在 Obsidian 设置 → 文件和链接中，把「附件文件夹路径」设为 raw/assets/。然后在设置 → 快捷键中搜索「Download」，绑定一个快捷键（如 Ctrl+Shift+D）。剪藏文章后按快捷键，所有图片下载到本地磁盘。这样 LLM 可以直接查看和引用图片，而不用依赖可能失效的 URL。
Marp
一种基于 Markdown 的幻灯片格式，Obsidian 有插件支持。可以直接从 wiki 内容生成演示文稿。
---
marp: true
theme: default
---
# Q4 业务复盘
来源：wiki/overview.md
---
# 关键指标
| 指标 | Q3 | Q4 | 增长 |
|------|-----|-----|------|
| 营收 | 4200万 | 5000万 | +19% |
Dataview
Obsidian 插件，可以对页面的 YAML frontmatter 运行查询，生成动态表格和列表。
---
type: entity
category: company
status: active
founded: 2020
---
TABLE founded, status
FROM "wiki/entities"
WHERE type = "company"
SORT founded DESC
qmd
一个本地 Markdown 文件搜索引擎，支持 BM25/向量混合搜索和 LLM 重排序，全部在本地设备上运行。同时有 CLI（LLM 可以通过 shell 调用）和 MCP 服务器（LLM 可以把搜索引擎作为原生工具调用）。
在小规模下索引文件就够用了，但随着 wiki 增长到数百个页面，你需要正式的搜索能力。
Git
Wiki 就是一个由 Markdown 文件组成的 git 仓库。你免费获得版本历史、分支和协作能力。
六、社区实现
Karpathy 的原始文档是一份抽象的设计文档，设计初衷是让你复制粘贴到自己的 LLM Agent 中。社区在此基础上做了大量具体实现。
llm_wiki（nashsu/llm_wiki）
一个跨平台桌面应用，基于 Karpathy 的方法论，做了大量增强。技术栈：Tauri v2（Rust 后端）+ React 19 + TypeScript。
核心增强：
| 增强 | 说明 |
|---|---|
| 两步思维链摄入 | LLM 先分析再生成 wiki 页面，质量显著提升 |
| 多模态图片摄入 | 自动提取 PDF 内嵌图片，调用视觉模型生成描述 |
| 四信号知识图谱 | 直接链接、来源重叠、Adamic-Adar、类型亲和 |
| Louvain 社区检测 | 自动发现知识聚类，内聚度评分 |
| 图谱洞察 | 惊奇连接与知识空白检测，一键触发 Deep Research |
| 向量语义搜索 | 可选的 embedding 检索，基于 LanceDB |
| 持久化摄入队列 | 串行处理，崩溃恢复，取消/重试 |
| Chrome 网页剪藏 | 一键捕获网页内容，自动摄入 |
| 审核系统 | LLM 标记需人工判断的项，异步处理 |
| 深度研究 | LLM 生成搜索主题，多查询网络搜索，结果自动摄入 |
两步摄入流程：
第一步（分析）：LLM 阅读资料 → 结构化分析
- 关键实体、概念、论点
- 与现有 Wiki 内容的关联
- 与现有知识的矛盾和张力
第二步（生成）：LLM 基于分析 → 生成 Wiki 文件
- 带 frontmatter 的资料摘要
- 实体页面、概念页面及交叉引用
- 更新 index.md、log.md、overview.md
- 需要人工判断的审核项
四信号关联度模型：
| 信号 | 权重 | 描述 |
|---|---|---|
| 直接链接 | ×3.0 | 通过 [[wikilinks]] 链接的页面 |
| 来源重叠 | ×4.0 | 共享同一原始资料的页面 |
| Adamic-Adar | ×1.5 | 共享共同邻居的页面（按邻居度数加权） |
| 类型亲和 | ×1.0 | 相同页面类型的加分 |
查询检索管线：
阶段 1：分词搜索（英文分词 + 中文 CJK 二元组）
↓
阶段 1.5：向量语义搜索（可选，LanceDB）
↓
阶段 2：图谱扩展（四信号关联度，2 跳遍历）
↓
阶段 3：预算控制（可配置 4K → 1M tokens）
↓
阶段 4：上下文组装（编号页面 + purpose.md + index.md）
llm-wiki-compiler（atomicmemory/llm-wiki-compiler）
本地 CLI 工具，1K+ stars。特点：
- 不可变资料源 + 生成的 Markdown
- 来源可追溯：claim-level provenance，如
^[paper.md:42-58] - 类型化 schema 和页面类型
- 置信度和矛盾元数据
- 图片/PDF/转录文件摄入
- 分块检索 + BM25 重排序
- MCP 工具支持
其他社区项目
- SeekLink（simonsysun/seeklink）：本地
.md仓库的语义搜索，行锚定检索 - Keel（Keel-Labs/keel）：Mac 应用，知识以纯 Markdown 存储，模型可替换
- SwarmVault（swarmclawai/swarmvault）：持久化多轮对话，Neo4j 导出，MCP 集成
- Eshel（alirezabbasi/eshel）：将 LLM Wiki 概念扩展到软件系统的持久化工程智能
- ΩmegaWiki（skyllwt/OmegaWiki）：23 个 Claude Code skills，9 种实体类型，双语支持
- Link（gowtham0992/link）：本地优先 Markdown wiki + MCP 服务器，SQLite FTS 搜索
七、为什么这个模式有效
知识复利
RAG 的知识是「一次性」的——每次查询从头开始，没有任何积累。LLM Wiki 的知识是「复利」的——交叉引用越建越多，综合判断越来越丰富，新资料能立即与已有知识产生关联。
打个比方：RAG 像每次做饭都从零开始买菜，LLM Wiki 像一个不断扩充的食谱本，每次加新菜谱都会更新食材索引和搭配建议。
维护成本归零
维护知识库中令人厌烦的部分从来都不在阅读或思考，全在记账上——更新交叉引用、保持摘要时效性、标注新数据与旧结论的矛盾、在数十个页面间保持一致性。
人类之所以放弃 wiki，是因为维护负担的增长速度超过了价值的增长速度。LLM 不会厌倦、不会忘记更新某个交叉引用、而且能在一次操作中触及 15 个文件。Wiki 能保持被维护的状态，是因为维护成本接近于零。
从 Memex 到 LLM Wiki
这个理念的精神源头可以追溯到万尼瓦尔·布什（Vannevar Bush）1945 年提出的 Memex——一个私人的、精心策划的知识存储，文档之间有关联路径。布什在《As We May Think》一文中描述了一个「个人所有书籍、记录和通讯的机械化存储设备」，核心是关联索引——信息应该按关联组织，而不是按僵硬的分类。
相比后来万维网实际走向的方向，布什的愿景其实更接近 Karpathy 描述的这个模式：私密的、主动策划的，文档之间的连接与文档本身一样有价值。他没解决的问题是：谁来做维护？LLM 解决了。
八、与传统 RAG 的对比
| 维度 | 传统 RAG | LLM Wiki |
|---|---|---|
| 知识存储 | 原始文档，未加工 | 编译后的结构化 wiki 页面 |
| 查询方式 | 每次从原始文档中检索 | 从已编译的 wiki 中检索 |
| 知识积累 | 无，每次从零开始 | 持续复利增长 |
| 交叉引用 | 无 | LLM 自动建立和维护 |
| 矛盾处理 | 无 | LLM 自动标注 |
| 维护成本 | 低（不需要维护） | 低（LLM 维护） |
| 适用场景 | 一次性问答、临时查阅 | 长期研究、持续积累 |
| 基础设施 | 需要向量数据库、Embedding | 纯 Markdown 文件 + 索引 |
两者不是替代关系，而是互补的。如果你只是偶尔查个文档，RAG 够用了。如果你要在一个领域持续深耕几个月，LLM Wiki 的复利效应才真正体现。
九、实践建议
起步
- 把 Karpathy 的原始文档（Gist 链接）丢给你的 LLM Agent（Claude Code、OpenAI Codex 等）
- 和 LLM 一起定义你的 Schema：wiki 的目录结构、页面类型、命名约定
- 从一个你熟悉的领域开始，摄入 3-5 篇资料
- 用 Obsidian 打开 wiki 目录，浏览图谱视图
保持纪律
- 逐条摄入，不要一次灌太多——每篇资料都值得被充分消化
- 好的答案归档回 wiki——不要让有价值的分析消失在聊天历史中
- 定期 Lint——每周花 10 分钟让 LLM 做健康检查
- 维护 Schema——随着理解加深，持续迭代你的规则文档
规模参考
- 10 个资料源、50 个页面：索引文件就够了，不需要搜索引擎
- 100 个资料源、数百个页面：索引仍然有效，考虑加 qmd 等搜索工具
- 1000+ 资料源：需要向量搜索和更完善的检索管线
十、Karpathy 原文留言精选
Karpathy 的 Gist 收获了 660+ 条留言，社区讨论非常活跃。摘选几条有价值的：
关于工具选择：多位开发者分享了自己的实现。有人做了 CLI 工具（llm-wiki-compiler），有人做了桌面应用（llm_wiki、Keel），有人做了 MCP 服务器（Link）。工具形态各异，但核心理念一致。
关于「wiki」这个词的争论：有人认为这些工具不应该叫「wiki」，因为缺乏协作编辑功能。反驳者认为语言会演化，核心在于信息的链接和可导航性，而非是否支持多人编辑。
关于来源可追溯：llm-wiki-compiler 实现了 claim-level provenance，每个声明可以追溯到原始资料的具体行号（如 ^[paper.md:42-58]）。这比简单的页面级引用更精细。
关于知识图谱：llm_wiki 项目实现了四信号关联度模型和 Louvain 社区检测，把 wiki 从「一堆互相链接的文件」升级为「可分析的知识网络」。图谱洞察功能可以自动发现惊奇连接和知识空白。
十一、总结
LLM Wiki 解决的核心问题是：用大模型处理过的知识，为什么留不下来？
传统 RAG 让 LLM 每次临时翻书，什么都没沉淀。LLM Wiki 让 LLM 替你维护一套持续更新的笔记——知识被编译一次就沉淀下来，越积越厚。人类负责筛选和思考，LLM 负责所有记账工作。
这个模式的精神源头是 1945 年 Vannevar Bush 的 Memex 构想——一个私人的、精心策划的知识存储，文档之间的连接与文档本身一样有价值。Bush 没解决的问题是「谁来做维护」，LLM 解决了。